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INTERNATIONAL BANKING SYSTEM AND METHOD 

FIELD OF THE INVENTION 

The present invention generally relates to systems and methods for 
10 conducting international banking operations and more particularly to providing 
an international infrastructure to a strictly local bank. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is related to and claims priority to U.S. provisional 
4 15 patent application Serial No. 60/182,469, filed February 15, 2000, entitled 

PRIVATE LABEL BANKING SYSTEM AND METHOD, the entirety of 
which is incorporated herein by reference. 

1 BACKGROUND OF THE INVENTION 

|i| 20 In order to conduct international banking operations, an extremely large, 

extensive, complicated and expensive infrastructure is absolutely required. Each 
country around the world has its own unique rules, regulations and requirements 
for who can provide banking services in that country. 

Typically, only large multinational financial institutions such as Chase 
25 Manhattan Bank, the assignee of the present invention, has the resources to 
provide such international banking services. Furthermore, even among large 
financial institutions, not all of them are members of the various clearing systems 
(e.g., Trans-European Automated Real-Time Gross settlement Express Transfer 
system (Target), Real-Time Gross Settlement systems (RTGS) and the Multi- 
30 Lateral Net Settlement systems (MLNS) in Europe). 

Because of the lack of an international presence, most banks accordingly 
had developed relationships with regional banks in different parts of the world. 
When a client of the bank (for example in the United States) desires to conduct a 
transaction in a different part of the world (Germany for example) the bank 
35 contacts its associate and coordinates the transaction with a correspondent bank. 
Accordingly, if a bank has clients which require international banking services, 
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the bank must establish and maintain relationships with a multitude of 
correspondent banks throughout the world. The maintenance of these various 
relationships is both cumbersome, expensive, and time consuming both with 
respect to the bank and its clients. 
5 International services typically required by customers include: direct 

payment initiation (high value (wire) and low value (Automated Clearing House 
(ACH) check disbursement)); receipt of credits of funds (both high value and low 
value including check deposits and collections as well as locks box processing); 
timely balance and transaction reporting; liquidity management (Automated 
10 Investment (Sweeps), netting and pooling of grouped accounts); timely and 
attentive customer service in the local time zone; and purchase of checks in 
foreign currencies at their local branch office. 

SUMMARY OF THE INVENTION 

15 The present invention solves the problems of the prior art as described 

above by providing banks with access to a previously inaccessible existing 
international infrastructure. Throughout this discussion, a bank without the 
international presence shall be denoted as a client bank whereas the bank 
implementing the system and method of the present invention is known as the 

20 provider bank. 

In order to initiate an international transaction through the provider bank, 
the provider bank first establishes on its system, a set of accounts for each of the 
customers of the client bank. These accounts are totally separate from the 
accounts of the customers of the provider bank and are therefore legally 

25 considered "on the books" of the client bank and are therefore not legally 
customers of the provider bank. 

In essence, this model provides a new branch of the client bank (the client 
bank environment) in the system of the provider bank. The client bank 
environment has its own Demand Deposit Account (DDA) module to process 

30 account entries and calculate interest and its own funds transfer module to initiate 
and to receive funds transfers. 

The primary interface into the funds transfer section in the client bank 
environment is to the funds transfer section of the provider bank environment. 
The funds transfer section of the provider bank is coupled to the systems which 
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constitute the international banking infrastructure that is able to process banking 
transactions on a global basis for the customers of the client bank. 

As a customer requests a particular international transaction, it is made 
known to the client bank directly by the customer. The client bank then 
5 communicates the requested transaction to the funds transfer section in the client 
bank environment within the system of the provider bank. The communication 
between the systems of the client bank and the provider bank systems can be 
made through a variety of means such as a CPU to CPU connection, a Value 
Added Network (VAN), a secure Electronic Data Interchange (EDI) transmission 

10 or even through the Internet. Once the client bank funds transfer section has 
received the requested transaction, it references the customer's accounts in the 
client bank environment (e.g., to debit the customer's account) and then transmit 
a transaction message (e.g., a payment message) to the funds transfer section of 
the provider bank environment. The funds transfer section of the provider bank 

15 can then process the transaction as if it was being made for one of the provider 
banks own customers (e.g., a high value wire transfer) through one of the clearing 
systems. 

The system as described above is further able to provide liquidity 
management services to the customers of the client bank, check printing 
20 capabilities and check clearing functionality as well as lockbox processing 
services. In a further embodiment of the present invention, the system can be 
used for settlement services between members of a Business to Business (B2B) 
exchange service (e.g., Chemconnect). 

25 BRIEF DESCRIPTION OF THE DRAWING(S) 

For the purposes of illustrating the invention, there is shown in the 
drawings a form which is presently preferred, it being understood however, that 
the invention is not limited to the precise form shown by the drawing in which: 

Fig. 1 illustrates an overview of the system and capabilities of the present 
30 invention; 

Fig. 2 depicts the client bank and provider bank environments within the 
system of the provider bank; 

Fig. 3 illustrates a first manner in which transaction information is 
communicated from the client bank to the provider bank; 
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Fig. 4 illustrates a second embodiment for transmission of transactions 
between the client bank and the provider bank; 

Fig. 5 illustrates an example of a check transaction; 
Fig. 6 depicts a lockbox processing embodiment of the present invention; 
5 Fig. 7 illustrates NOSTRO account reconciliation; and 

Fig. 8 depicts a business to business settlement and international banking 
embodiment of the present invention. 



DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
1 0 Figure 1 illustrates a summary of the system of the present invention and 

m some of the functionality provided thereby. The client bank 100 is typically a 

? ;; § smaller local bank without any infrastructure for providing its customers with 

: 'l international banking services. The client bank 100 can either be based in the 

hi 

i.g U.S., or based anywhere throughout the world. In the ever increasing 
1^ 1 5 globalization of the economy in both the U.S. and throughout the world, the 

q customers of client bank 100 are increasingly finding it necessary to conduct 

l m banking transactions in foreign countries. For example, a United States 

[11 manufacturing corporation based in Cleveland Ohio is now finding itself 

1 purchasing parts in Taiwan for assembly in Mexico for shipment to a customer in 

'■•is™ 

{ i| 20 South Africa. This customer therefore has a need to both pay the supplier in 

Taiwan, issue checks to its employees in Mexico and to obtain payments form its 
customers in South Africa. The client bank 100 of the customer in Cleveland 
Ohio is incapable by itself, of conducting each of these transaction for its 
customer. Accordingly, customer 100 develops a relationship with provider bank 
25 120 that has the international infrastructure for providing all of these international 
banking services to the customer in Cleveland. In a preferred embodiment of the 
present invention, the services provided by provider bank 120 to client bank 100 
are private labeled such that the customer of client bank 100 is unaware that 
provider bank 120 is even involved. 
30 As client bank 100 receives a request for an international banking 

transaction from one of its customers, client bank 100 appropriately formats the 
transaction as a message for transmission to provider bank 120 on link 110. As 
will be further described below, link 110 between the two banks can be either a 
direct dial up connection from CPU to CPU, a Value Added Network (VAN), a 
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leased line, or the Internet. The format of the message between client bank 100 
and provider 120 can be one of several including Accredited Standards 
Committee (ASC) standard ASC XI 2 820, EDI Administration, Commerce and 
Transport standard (UN/EDIFACT or EDIFACT), a secure EDI format or a 
5 proprietary format as described below. 

The systems in provider bank 120 are capable of receiving the transaction 
message from client bank 100 and capable of performing the requested banking 
transaction. As illustrated in Figure 1, these transactions include the printing of 
checks both within the U.S. and around the world 130, initiating a U.S. domestic 
10 ACH transaction 140, initiating an international ACH transaction 150, a wire 
3 transfer throughout the world of U.S. dollars 160 and a wire transfer of currency 

y in any denomination including Euros and mixed denominations 170. As will be 

h 4 further described below with respect to the remainder of the Figures, provider 

^ bank 120 is capable of performing a wide variety of banking services such as the 

|! 1 5 reception of credits and payments and lock box processing for example. 

^ Figure 2 illustrates in more detail the system of the present invention. As 

p illustrated in Figure 2, the funds processing systems of the provider bank 120 are 

J logically divided into 2 environments, a client bank environment 122 and a 

1 provider bank environment 124. As previously described, the client bank 

9 20 environment 122 which holds the accounts 205 of the client banks 100 customers, 
is an entirely logically separate environment which allows the customer's 
accounts 205 to be considered to be held on the books of the client bank 100. 
Each of the environments 122 and 124 have been illustrated as containing two 
main components. The provider bank embodiment contains an internal 
25 processing section 210 which is coupled to the accounts 215 of the provider bank. 
Similarly, the client bank environment 122 is illustrated as having a 
complimentary client bank internal processing section 200 coupled to the 
accounts 205 of the customers of the client bank 100. Although simplified in the 
present Figure in a single section 210 or 200, the internal processing sections are 
30 appreciated as containing all of the processors, software and interfaces for 
maintaining the accounts 205, 215 interfacing with external sources (e.g., client 
bank 100 and clearing and exchange systems 220, 230) and generating reports 
and statements (240, 245, 250 and 260). 
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As previously described, the client bank 100 communicates with provider 
bank 120 using link 110. As further described below, there are a variety of 
structures and data formats which can be used to provide this communication link 
110. The link 110 is illustrated as being bi-directional as the client bank 100 
5 communicates payment messages as well as Advice To Receive (ATRs) to the 
internal processing section 200 while the internal processing section 200 
communicates back to the client bank 100 various statuses and reports, as well as 
funds transfers to and from the client bank 100 and the customers account 205. 

The internal processing section 200 for the client bank is shown as 

10 generating various statements and reports. Specifically, the processing section 
200 generates statement data 240 for the customers of the client bank. This 
statement data can be formatted and sent directly by the internal processing 
section 200 to the customers of the client bank 100. Alternatively, the statement 
data can be transmitted back to the client bank 100 for its own generation of the 

15 statements for its clients or alternatively sent to a third party for generation of the 
statements on behalf of the client bank 100. 

The internal processing section 200 also generates financial reports 245 
such as a General Ledger (GL) movement report as well as a Management 
Information System (MIS) report. The financial reports 245 are generally 

20 accounting reports that are transmitted to the client bank 100 in order that the 
client bank 100 may update their systems and books. The financial reports 245 
can be sent either electronically, by hardcopy or by both methods. 

One additional report illustrated in Figure 2 as being generated by the 
internal processing section 200 is a billing data report 250. The billing data 

25 report 250 informs the client bank 100 of the banking actions undertaken by the 
provider bank 120 on behalf of the customers of the client bank 100 and the 
corresponding charges for the banking actions. Presumably, these charges from 
the provider bank 120 to the client bank 100 are passed onto the customers of the 
client bank 100 that caused the charges to be incurred. 

30 Although only a single client bank environment 122 is illustrated in Figure 

2, it is readily appreciated that a similar bank environment is established for each 
client bank 100 making use of the present invention. In a preferred embodiment 
of the present invention, each of these client bank environments 122 would 
interface with the single provider bank environment 124 illustrated in Figure 2. 
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As further described below, each client bank 100 additionally has its own account 
215 in the provider bank environment 124. 

As briefly described previously, the provider bank environment 124 
includes an internal processing section 210 that is coupled to the accounts 215 of 
5 the provider bank. Each of the client banks 100 using the service of the present 
invention has at least one account 215 with the provider bank. In a preferred 
embodiment, the client bank 100 has several accounts 215, each in a different 
currency for conducting transactions in the different currencies. In further 
preferred embodiment, each customer of the client bank actually has two 
10 accounts 205 in the client bank environment 122 in order to provide for double 
:;:! entry accounting practices. 

^ As illustrated in Figure 2, the two processing sections 200 and 210 

sj communicate both payments and credits. This communication is accomplished 

^ via internal messaging systems within provider bank 120. Payments typically 

II 15 originate from the customer accounts 205 and credits typically are received by 

5 processing section 210 from external sources such as clearing systems 220 and 

^ 230 for the crediting of customer accounts 205. 

If The following is an example of the operation of the system in executing a 

1 foreign payment. The customer of the client bank 100 (not shown) contacts client 

□ 20 bank 100 and instructs them to make a payment. For example, the customer 

might instruct client bank 100 to perform a wire transfer to the German bank of 
one of its suppliers. Client bank 100 formats the transaction message and 
communicates it to the provider bank 120 over link 110. As further described 
below, there is typically a front end processing section (not shown in Figure 2) 
25 within provider bank 120 which receives the transaction from client bank 100 and 
forwards the transaction message to processing section 200. Upon its receipt, 
processing section 200 debits the account 205 corresponding to the customer and 
transmits the funds along with a payment message to processing section 210 
within the provider bank environment 124. In a preferred embodiment, the 
30 transfer of funds from a customer account 205 to the processing section 210 is 
immediate via a memo post transaction. 

Upon receipt of the funds and the transaction message from processing 
section 200, the processing section 210 formats the payment instruction in 
accordance with the particular clearing system 220 that is going to be used to 
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transfer the payment to the German bank. For example, the German bank might 
only be a member of the German RTGS system and the processing section 210 
would format the payment for transmission to this clearing system. Alternatively, 
the German bank of the supplier might be a member of the German MLNS 
5 clearing system which requires a different formatting of the payment message. 
Once the payment message has been formatted for the appropriate clearing 
channel, it is transmitted to this clearing channel for ultimate receipt by the 
German bank. If the payment is going through a correspondent bank in a foreign 
country rather than directly through a clearing system 220, the payment 
10 instruction is forwarded to the correspondent bank through the Swift or Telex 
^1 system 230. 

Figure 3 illustrates an embodiment of the present invention in which 
instructions for financial transactions are communicated from client bank 100 to 
; :0 provider bank 120 through a proprietary file structure. Figure 3 further illustrates 

^ 15 the processing of payments and credits to and from provider bank 120 through 

□ local clearing systems 370 to and from beneficiaries/remitters 380. In the 

example illustrated in Figure 3, one or more of the customers 300 of client bank 
f|| 100 wishes to execute an international transaction. Again, the customers can be 

located in a foreign country and desiring a payment into the U.S. or in the U.S. 
3 20 and desiring a payment into a foreign country. Alternatively, the system depicted 

M in Figure 3 can be used for a foreign country to a foreign country payment. Once 

one or more payment transactions have been received by client bank 100, they are 
formatted into a multiple transaction format and transmitted to provider bank 120 
in file 310. The format of the payments in file 310 are such that multiple 
25 payment types and currencies are capable of being included in a single file 310. 
This includes Clearing House Interbank Payment System (CHIPS) format, 
FedWire, book, U.S. domestic ACH payments, and Euro or other foreign 
currency payments. Wire, international ACH payments, checks and drafts are 
also capable of being included in the single mixed file 310. As previously 
30 described, the formats for the individual payments can be in UN/EDIFACT, 
ANSI X12 as well as other formats. 

In a preferred embodiment of the present invention, file 310 is 
communicated from client bank 100 to provider bank 120 over the public 
Internet. The public Internet provides a very cost effective means of 
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communicating between client bank 100 and provider bank 120. This 
communication over the public Internet is capable only due to extensive security 
means. In the preferred embodiment, three different types of public/private key 
infrastructure (PKI) security models are supported. These security models 
5 include Trusted Link Templar™, RSA and Entrust™. All three of these security 
models incorporate full strength encryption, digital signature authentication, 
digital certificates, and non-repudiation. In this manner, client bank 100 and 
provider bank 120 can safely securely and confidently transmit financial 
transactions over the public Internet. In an alternative embodiment, a Value 
10 Added Network (VAN), leased line or direct CPU to CPU communication links 
are options. 

In the preferred embodiment using the Internet, the file 310 is generated 
by the operating system within the client bank 100. The file 310 is then 
forwarded to the agreed upon security module such as Trusted Link Templar™. 

15 The security module encrypts the file 310 and digitally signs the message. The 
encrypted signed file 310 is then formatted for particular agreed upon format. 
For example, the file 310 can be forwarded to an EDI translator where it is 
translated into a ANSI X12 or EDIFACT message format. 

The file 310, encrypted, digitally signed and formatted is enclosed in a 

20 secured e-mail Simple Mail Transfer Protocol (SMTP) format and sent through 
the client bank 100 firewalls to the Internet. The gateway 320 within provider 
bank 120 receives this secured e-mail message 310 and routes it to the server 
where Templar™ resides. In the embodiment depicted in Figure 3, it is assumed 
that the Templar™ server resides within the gateway 320 itself, but as 

25 appreciated by those skilled in the art, the Templar™ server can be separate from 
the gateway 320. Templar decrypts the file 310 and verify the digital signature 
for authentication. Once the gateway 320 has authenticated the digital signature, a 
non-repudiation message is sent back to client bank 100 indicating that the 
provider bank 120 has validated the sender's identity and confirmed that the file 

30 was received unchanged. The financial transaction(s) contained in file 310 are 
then forwarded to the payment processor 330 for processing. EDI translation as 
well as the application of a second level of authentication against an EDI message 
would take place at this point as well. The payment processor 330 separates out 
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each of the transactions for routing the payment. The routing decision primarily 
depends on the destination of the payment as well as its value. 

As illustrated in Figure 3, low value payments, typically below fifty 
thousand United States dollars (USD) are transmitted by one method whereas 
high value payments are transmitted via wire. Low value payments passed 
through a hub 340 within provider bank and are forwarded to either the main 
provider branch 360 or a local provider branch 350 that is more convenient with 
respect to the ultimate destination of the payment. For example, if the 
beneficiary 380 is in France, the low value payment will be forwarded to a local 
provider branch 350 located in France. If there is no local branch 350 of the 
provider bank 120, the low value payment is transmitted by the hub 340 to the 
main provider branch 360. Branch 360 is then able to transmit the low power 
payment value through a local clearing system 370, perhaps through a 
correspondent bank with which the provider branch 360 has a previous 
relationship. 

The local clearing system 374 low value payments can be the international 
ACH system, local GIRO systems or other local banking mechanisms with which 
the provider bank 120 has previously established relationships. The local 
clearing system 370 is then able to provide the beneficiary with the funds. 

If a foreign currency exchange (FX) is required with respect to the 
payment, such FX preferably occurs in the main provider branch 360. The client 
bank environments 122 and the provider bank environment 124 previously 
described with respect to Figure 2 are preferably embodied in the payment 
processor 330. In a preferred embodiment, the payment processor 330 is located 
at the main provider branch 360, but its functions can be embodied at local 
provider branches that maintain the relationships with the client bank 100. 

High value payments, greater than fifty thousand USD, are transmitted by 
the payment processor 330 to the main provider branch 360. As previously 
described, the main provider branch 360 uses local clearing systems 370 such as 
RGTS, MLNS, European Banking Association (EBA) Euro clearing, 
correspondent banks, and the Trans-European Automated Real-time Gross 
settlement Express Transfer (TARGET) system. 

Although the above has described the process followed for payments from 
client bank customers 300 to beneficiaries 380, a reverse of the process is used 
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for credits to the customers 300 (i.e., payments from remitters 380). How credits 
are specifically handled are subject to predetermined contractual arrangements 
with the particular client bank 100. For example, a credit might be deposited in 
the customer's account 205 (see Figure 2) or might be forwarded directly to the 
client bank 100 for deposit in the customer's account (not shown ) at the client 
bank 100. 

Figure 4 illustrated an alternative embodiment in which payments and 
credits are transmitted. In the embodiment illustrated in this figure, financial 
messages are communicated between client bank 100 and provider bank 120 
using the SWIFT network. SWIFT is a bank owned cooperative supplying secure 
messaging services and interface software employed by over six thousand seven 
hundred financial institutions in close to two hundred countries. As most 
significant client banks 100 subscribe to the SWIFT network, this interface for 
communicating financial messages significantly expands the service of the 
present invention. 

Figure 5 illustrates an embodiment of the present invention for the 
issuance of checks. The check request 500 are transmitted by the client bank (not 
shown) to the client bank internal processing section 200 within the provider 
bank 120. The structure of the provider bank 120 is the same as previously 
illustrated. The client bank current accounts 205 has been further illustrated as 
including the accounts for its customer's Corporation A 206, Corporation B 207 
and Corporation C 208. A client bank 100 typically has three to four thousand 
different accounts (e.g., 206-208) contained in the client bank accounts 205. 

As the internal processing section 200 receives the check request, the 
requested amount is debited from the customer's account 206-208, in order to 
effectuate the issuance of the check. At this point, as shown in Figure 5, there are 
three different ways in which the actual physical check may be issued. In the first 
embodiment, the check request is transmitted to the provider bank internal 
processing section 210 in the provider bank environment 124. The physical 
check can then be printed and issued from the processing section 210 and directly 
forwarded to the beneficiary, e.g., beneficiary A 530, beneficiary B 535 or 
beneficiary C 540. Alternatively, the internal processing section 210 may use one 
of the other payment mechanism such as shown in Figure 3 to have the check 
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physically printed and forwarded to the beneficiary, 530-540, by a local 
correspondent bank. 

In the second and third embodiment, the client bank internal processing 
section 200 issues instructions to either the home office of the corporation 510 or 
5 the home office of the client bank 520 in order to have the check printed at either 
of these locations. In these embodiments, a check design and print module 
(included in 510 and 520) is provided to the corporation or the client banks' home 
office that allows the users to create and customize check layouts to suit their 
particular requirements, for example requirements such as the local currency and 
10 country standards. This capability of the present invention eliminates the need 
;:5 . for either the corporation or the client bank to inventory check stock. This 

li feature, also known as multi-bank/multi-currency capability, enables check 

s * printing to be drawn on any bank anywhere in the world in which an account is 

} j3 maintained and which the currency format is available. If the client bank has 

W3 15 several branches, each of the branches can make use of the check printing 

S capabilities of the present invention by accessing the server 520 in the client bank 

home office. Similarly if a corporation has many divisions, each of the divisions 
£f 8 can make use of this capability by accessing the multi-bank/multi-currency 

;;3 capability in the corporations home office 510. In either case, the home office of 

^ 20 the client bank or the treasurer of the corporation is able to monitor activity from 

^ all locations on line at the home office. 

One further feature of the present invention with respect to checks is its 
clearing capabilities. The present invention provides a reliable, straight forward 
procedure for clearing multi-currency checks denominated either in National 
25 Currency Units (NCU) (e.g., USD) or Euros. The proceeds of a check so cleared 
can be credited into an account in the currency in which the check was drawn or 
can be converted by provider bank 120 and credited to any account held with 
provider bank 120 throughout the world. Items in all currencies (including 
Euros) receive credit according to a negotiated availability schedule (under usual 
30 reserve). In a preferred embodiment "third country" checks, i.e., checks 
denominated in a currency other than the currency of the country where the 
drawee bank is resident (e.g., a USD check drawn on a French bank in France), 
and checks with a face value exceeding $50,000 equivalent are handled on a 
collection basis. 
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A further advantage of the present invention can also be explained with 
respect to Fig. 5. This advantage is liquidity management. In a preferred 
embodiment of the present invention, the provider bank 120 pays interest on 
individual DDA balances maintained in the client bank current accounts 205 
5 (e.g.. accounts 206-208). The sweeping of funds for investment purposes is not 
required, which simplifies reconciliation of the accounts. In a preferred 
embodiment, interest is accrued daily and credited monthly on the first day of the 
succeeding months. Interest rates can be set according to balance tiers (e.g. 
higher balance equals higher rate). In a further embodiment, interest is 
10 automatically adjusted for back values up to six months. 
,^ A further feature of liquidity management is zero balance and target 

>|! balance sweeps. In a preferred embodiment, these sweeps are automatic and are 

; T ! used for concentration of funds of related accounts. For example, a sweep can be 

v9 made from the accounts of various divisions of a corporation into a single 

^ 15 corporate account. Furthermore, such sweeps can be performed to transfer funds 

ril from a collection account into a disbursement account. Both types of sweeps can 

^ be used to concentrate funds in the same currency or between an NCU and Euro, 

flj In a preferred embodiment, provider bank 120 automatically adjusts investments 

i«5 and interest for bank valuations. One of the main purposes of such sweeps is that 

20 the provider bank, in a preferred embodiment, pays a preferable interest rate if the 
M balance of the account is above a minimum threshold. Sweeping funds from 

various accounts into a single account enables the customers to more easily 
achieve this minimum balance requirement. 

Liquidity management according to the present invention also involves 
25 multiple account pooling. Credit and debit balances in the same currencies are 
notationally offset to reduce overdraft interest. There is no actual movement or 
commingling of funds employing this offset. Euro and NCU accounts held in the 
name of one customer can be part of the same pool. All accounts in the pool 
operate autonomously, earning and paying credit and debit interest on the basis of 
30 the individual daily balances and assigned rates. A separate "pooled interest" 
calculation is made on the aggregate net balance of the pool. The pooling effect 
(the pooled interest net of the interest paid to the individual accounts) is normally 
credited to a "pool leader" account. In this manner, the customer is provided with 
an incentive to have all of his accounts with provider bank 120 without being 
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penalized for having a substantial sum of money spread across several accounts 
in several different currencies. The pooling benefit is calculated monthly and 
reports are generated that detail interest benefit allocation both at the pool leader 
and individual account levels. 
5 Fig. 6 illustrates a lock box processing embodiment of the present 

invention. As known to those skilled in the art, lockbox processing is a service in 
which the bank receives payments on behalf of a customer subscribing to the 
lockbox service. For example, the bank may process all of the incoming 
payments for a telephone company when its customers pay their telephone bills. 

10 As illustrated in Fig. 6, each of the remitters 615-625 forward their payments, 
ultimately, to a central delivery point 610. Remitter C 625 is illustrated as 
delivering its payment to a remote delivery point 630. The remote delivery point 
in turn forwards all of the payments it receives to the central delivery point 610. 
On a periodic basis, e.g., daily, the central delivery point 610 transmits all 

15 of the receipt payments to the lockbox processing system 600 within the provider 
bank 120. The provider bank 120 opens the mail and sorts it by account and 
currency. Within lockbox processing system 600 there exists the hardware (not 
shown) to perform the following traditional lockbox operations. The checks 
included with the payments are processed using normal financial processing for 

20 incoming checks. This processing includes capturing the MICR data and creating 
a database of the information related to each check as well as an image of the 
check itself Images are separately created for each of the invoices and other 
remittances contained in the envelopes from the central delivery point 610. Data 
is manually entered from the invoices and is associated with the images of the 

25 invoices as well as the images and data for the checks. All of the data for a 
particular remittance is cross referenced such that a user may look at the data and 
images for the check as well as the data and images for the invoices. 

In the financial processing of the checks, the credits are passed to the 
internal processing section 210 for the crediting of the account for the client bank 

30 in account section 215. The internal processing section 210 furthermore advises 
the client bank internal processing section of the credits which then accordingly 
updates the specific account of the lockbox owner (206-208) in the client bank 
current accounts section 205. 
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Once the processing of all of the incoming mail by the lockbox processing 
system 600 is completed, the lockbox processing system 600 creates the lockbox 
database 640 which contains the images and data associated with both the checks 
and the invoices contained within each payment. As illustrated in Fig. 6, the 
5 client bank 100 has access to this lockbox database 640 for the purposes of 
generating statements for its customers and/or for exception, query and 
reconciliation purposes. In a further embodiment, the customers of the client 
bank 100 have access to the lockbox database 640, either directly, or through the 
client bank 100. 

10 Figure 7 illustrates the system method of the present invention for 

reconciling payments and credits. In banking terms this is known as Nostra 
reconciliation. Accounts which one bank maintains on behalf of another bank are 
know as Nostro and Vostro accounts. From the viewpoint of a first bank, a 
Nostro account is an account that the first bank maintains on behalf of a second 

1 5 bank and a Vostro account is the account which the second bank maintains for the 
first bank. Reconciliation according to the present invention is a two stage 
process. The example illustrated in Figure 7 is a reconciliation of a payment 
through a local clearing system 705 destines for the account 740 of a customer of 
the client bank. Firstly, there is a reconciliation in the books of the provider bank 

20 124 and secondly in the books of the client bank 122. 

In the example of Figure 7, a $3 million dollar payment in favor of a 
customer of the client bank is cleared through a local clearing system 705. The 
funds are received by a correspondent of the provider bank and credited to the 
Vostro account 710 of the provider bank maintained at the correspondent bank. 

25 The funds are then transferred from the Vostro account 710 at the correspondent 
bank to the provider bank 120. Specifically, the correspondent bank in one 
embodiment of the present invention generates a SWIFT MT100 or MT202 
payment instruction to the provider bank. This payment instruction results in a 
series of credits and debits in the accounts within the provider bank environment 

30 124 and the client bank environment 122. The first is a debit against the provider 
bank Nostro account 715, 

A first reconciliation is required to match the entries in the general ledger 
of the provider bank environment 124 and the entries relating to the same 
transaction processed by the correspondent bank. A general ledger entry for the 
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$3 million is fed from the provider bank Nostro account 715 to the Nostro 
reconciliation system 725 in the provider bank environment 124. This entry is 
then reconciled with a corresponding entry from the correspondent bank. In 
addition to the MT100 payment instruction with respect to the $3 million credit 
5 described above, the correspondent bank transmits an MT950 statement of 
account to the Nostro reconciliation system 725 in the provider bank environment 
124. The first reconciliation process requires the matching of an entry on the 
MT950 statement with respect to the $3 million transaction to the related entry on 
the provider bank ledger. The process is carried out in the Nostro reconciliation 
10 system 725 in the provider bank environment 124. Any unmatched item is 
^ referred to an investigation system 730. 

II The second financial transaction to occur is the crediting of the $3 million 

.1 from the provider bank environment 124 to the customer account 740 in the client 

y3 bank environment 122. In this transaction, the provider bank environment 124 is 

^ 15 essentially acting as a correspondent for the client bank environment 122. As 

rg shown in Figure 7, the client bank Vostro account 720 issues a SWIFT MT910 

I payment instruction that is transferred by the internal messaging system described 

f|j above to the client bank Nostro account 735. This results in the crediting of the 

•S $3 million to the customer's account 740. A separate reconciliation is required to 

20 match entries in the client bank Nostro account 735 relating to the same 
M* transaction to the entries processed by provider bank environment 124 as 

correspondent for the client bank environment 122. 

The client bank environment 122 matches transactions in the same way as 
described above with respect to transfers to the provider bank environment 124 
25 from the correspondent bank. Specifically, the ledger entries are fed from the 
client bank Nostro account 735 to the Nostro reconciliation system 745. Similar 
to the statement described above, provider bank environment 124, acting as a 
correspondent bank, transmits an MT950 statement of account to the Nostro 
reconciliation system 745 in the client bank environment 124. This MT950 
30 statement reflects the $3 million transaction between the provider bank 
environment 124 and the client bank environment 122. The Nostro reconciliation 
system 745 then attempts to matches the MT950 statement entries to the ledger 
entries. As with the first reconciliation, any unmatched items are referred to the 
investigation system 750. 
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Although the above description has been with respect to a incoming credit 
from a local clearing system, it is clear that the same reconciliation process is 
performed for outgoing payments from a customer account (e.g., account 740). 
Any transaction carried out by the provider bank environment 124 as 
5 correspondent for the client bank environment 122 results in a debit or credit to 
the relevant client bank Vostro currency account (e.g., account 720) in the 
provider bank environment 124. The provider bank environment 124 generates 
debit entries when they receive an MT100 from the client bank environment 122. 
For incoming receipts the credit entry will be generated by an MT100 or MT202 
10 received from the external correspondent bank. As described above, when the 
provider bank environment 124 processes an incoming receipt it will also 
1 generate an MT910 and send this via the internal messaging system to the client 

*j bank environment 122. This standard process for all currencies leads to a very 

high automatic match rate in the Nostro reconciliation systems 725, 745. In a 
9 15 preferred embodiment, the Nostro reconciliation systems 725, 745 operate on a 

^ reconciliation processor. 

Fig. 8 illustrates an alternative embodiment of the present invention for 
use with a business-to-business (B2B) exchange service. The environment within 
:;:!! provider bank 120 is essentially the same as depicted with respect to Figs. 2, 5 

^ 20 and 6, the difference being that the environment 123 is an environment for the 
exchange as opposed to an environment for the client bank. The exchange 
current accounts 206 includes an account (211-213) for each of the members 810 
of the exchange. In a preferred embodiment, a membership in the exchange 
requires a settlement account (21 1-213) to be held with the exchange. 
25 In operation, the members 810 go to the exchange website 800 in order to 

initiate and to conclude a transaction. A buying member is able to view an 
invoice for the transaction on the exchange website 800. Through a link on the 
website 800 the member 810 is able to contact his own bank 820 in order to 
instruct his bank to pay proceeds to the provider bank 120 for the account of the 
30 exchange for credit to the seller's account (211-213) with the exchange. 

The provider bank 120 upon receipt of the payment instruction sends an 
advice of credit to the seller via a secure postmarked e-mail. The seller can then 
log onto the exchange website 800 and using a link on the website 800 can access 
the provider bank 120 and instruct the exchange internal processing section 201 
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to pay the proceeds via its account at Chase (211-213) to the seller's bank 820 for 
the seller's account or to any bank designated for any account designated. 

As discussed above, this embodiment of the present invention allows any 
B2B website to safely and securely provide settlement services to its members 
5 without the significant and extensive costs of building an infrastructure for 
performing such settlement services. Furthermore, as discussed above, the 
present invention is able to provide foreign services as well as international 
banking services as required by the members of the exchange (e.g., payments 
and/or credits to and/or from foreign countries). 
10 Although the present invention has been described in relation to particular 

sSift embodiments thereof, many other variations and modifications and other uses 

)|1 will become apparent to those skilled in the art. It is preferred, therefore, that the 

y, present invention be limited not by the specific disclosure herein, but only by the 

! H 

i.g appended claims. 

; ft 
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